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REMARKS 

Claims 1-21 are pending in this application. By this Amendment, claims 1, 4, 8, 10, 14, 
16 and 18 are amended for clarity (and not for reasons relating to patentability). 

The Office Action objects to claim 16 because of informalities. The above amendment 
obviates the grounds for objection. Withdrawal of the objection is respectfully submitted. 

The Office Action rejects claims 1, 8, Hand 18 under 35 U.S.C. §112, first paragraph, as 
failing to comply with the enablement requirement. In particular, the Office Action questions 
how a client requesting an IP address to be allocated is capable of responding to a ping issued to 
an IP address. The rejection is respectfully traversed. 

The present specification clearly describes at least one embodiment in which a DHCP 
server receives an IP address allocation request for a DHCP client. See step SI of FIG. 3. The 
specification then describes that the DHCP server may issue an ICMP ping packet. See step S3 
of FIG. 3. FIG. 4 then shows features relating to when a reply to the ICMP ping packet is 
received. A determining module 20 of the DHCP server determines whether the reply is from 
the DHCP client requesting the IP address allocation or from another DHCP client. Based on 
this determination, either (1) the DHCP server determines that no other host (or DHCP client) 
has an IP address the same as the requested IP address (if the reply is received from the DHCP 
client making the IP address allocation request) or (2) the DHCP server obtains a new IP 
address and issues a new ICMP ping packet (if a reply is received from other than the DHCP 
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client making the IP address allocation request). See paragraphs [46]-[48] of the present 
specification. 

The Office Action appears to question whether a reply to a ping may be received from 
the same client that issued an IP address allocation request. The specification is very clear in its 
teaching and would be understood by one skilled in the art. That is, the present application 
relates to preventing duplicative allocation when IP addresses are allocated by a server. The 
present specification relates to reconfirming the present condition of IP allocation by 
determining that a reply to an ICMP ping request is from a DHCP client. S7-S10 of FIG. 4 
relate to these features. It is respectfully submitted that these features are not known in the prior 
art and thus have led to the issuance of the rejection under 35 U.S.C. §112, first paragraph. 
However, when the specification is read by one skilled in the art, the teaching of how to make 
and use the features are very clear. 

It is respectfully submitted that one skilled in the art would be able to make and use the 
claimed features. In particular, one skilled in the art would be able to make and use a server that 
includes a determining module and a first operation module as recited in independent claim 1. 
In other words, one skilled in the art would know how to determine whether a reply to an ICMP 
ping packet came from a DHCP client requesting an IP address allocation or from another 
DHCP client. For at least similar reasons, one skilled in the art would know how to make and 
use the features of the other independent claims 8, 14 and 18. Withdrawal of the rejection under 
35 U.S.C. §112, first paragraph, is respectfully requested. 
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The Office Action rejects claims 1-21 under 35 U.S.C. §102(b) over "Join server technical 
help: Chapter 5: Server/Security Parameter," technical manual from UC Davis Information 
Resources Unix Help website (hereafter JOIN). The rejection is respectfully traversed. 

Independent claim 1 recites a determining module that determines whether a reply to the 
ICMP ping packet came from the DHCP client requesting the IP address allocation or from 
another DHCP client. Independent claim 1 also recites a first operation module that conducts a 
DHCP procedure using the registered relevant event information if the reply is from the DHCP 
client requesting the IP address allocation, and that changes the registered relevant event 
information through the ICMP module and issues a new ICMP ping packet if the reply is not 
from the DHCP client. 

JOIN does not teach or suggest all these features. In particular, the Office Action cites 
JOIN'S Ting BOOTP Client' and Ting Timeout' on page 8 as corresponding to these claimed 
features. However, these features do not suggest the ability to determine whether a reply to an 
ICMP ping packet came from a D HCP client (requesting the IP address allocation) and if so. 
then conducting DH CP procedure using registered relevant event information. Rather, the cited 
section of JOIN merely relates to a server sending an ICMP echo and if a reply is received, then 
Jogging an error. See in particular, the first two lines of the section entitled Ting BOOTP 
Clients.' As such, JOIN does not teach or suggest all the features of independent claim 1. 

Each of independent claims 8, 14 and 18 defines patentable subject matter at least for 
similar reasons as discussed above. That is, independent claim 8 recites conducting a DHCP 
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procedure using the registered relevant event information and erasing the registered relevant 
event information from the DHCP ping entry when a reply to the ICMP ping packet is received 
from the DHCP client requesting the IP address allocation, and changing the relevant event 
information registered in the DHCP ping entry and issuing a new ICMP ping packet when the 
reply to the ICMP ping packet is from another DHCP client. Still further, independent claim 14 
recites a determining module that determines whether a reply to the issued ping packet came 
from a first client that requested the IP address allocation or from a second client, and 
a first operation module that allocates an IP address to the first client if the first client is 
determined to have sent the reply. Finally, independent claim 1 8 recites determining whether a 
reply to the issued ping packet came from a first client that requested the IP address allocation or 
from a second client, and allocating the IP address to the first client, if the first client is 
determined to have sent the reply. JOIN does not teach or suggest these features of 
independent claims 8, 14 and 18 for at least the reasons as set forth above. 

Each of the dependent claims depends from one of the independent claims and therefore 
defines patentable subject matter at least for this reason. In addition, each of the dependent 
claims recites features that further and independently distinguish over the applied references. 

CONCLUSION 

In view of the foregoing, it is respectfully submitted that the application is in condition 
for allowance. Favorable consideration and prompt allowance of claims 1-23 are earnesdy 
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solicited. If the Examiner believes that any additional changes would place the application in 

better condition for allowance, the Examiner is invited to contact the undersigned attorney, 

David C. Oren t at the telephone number listed below. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. 1.136 is 

hereby made. Please charge any shortage in fees due in connection with the filing of this, 

concurrent and future replies, including extension of time fees, to Deposit Account 16-0607 and 

please credit any excess fees to such deposit account. 

Respectfully submitted, 
FLESHNER & KIM, LLP 

Daniel Y.J. Kim 
Registration No. 36,186 
David C. Oren 
Registration No. 38,694 

P.O. Box 221200 
Chantilly, Virginia 20153-1200 
(703) 766-3701 DYKoco/kah 
Date: July 25, 2005 

Please direct all correspondence to Customer Number 34610 
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